(レポート) AWS Black Belt Tech Webinar: AWS上でのスピードと高可用性を両立したゲームインフラの構築と事例 #awsblackbelt

AWS Black Belt Tech Webinarレポート

#AWS

#イベントレポート

佐々木大輔

2016.12.20

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

本記事は12/20(火)にオンラインで開催されたAWS Black Belt Tech Webinar「AWS上でのスピードと高可用性を両立したゲームインフラの構築と事例」のレポートです。講師はアマゾンウェブサービスジャパンソリューションアーキテクトの森祐孝さん。

レポート

Lumberyardについて

ゲームエンジン。 Twitch、Double Helixなどのゲームテクノロジーを組み込んだもの。無料なので是非使っていただきたい。

なぜゲームインフラでAWSを選ぶのか？

重いものを持ち上げることはビジネスの中核ではない。ゲームライフサイクルは高速。ゲーム業界は日々高速に進歩している。通常ゲーム業界はアジャイル開発、数分単位でキャパシティとサービスが変動している。 AWSはどこをサポートできるのか？ゲームのライフサイクルとは。プランニング→開発/テスト→ローンチ後の急速な成長期→ゲームが安定化→ユーザー数減少。

プランニング

世界中のデータセンター。 AWSには現在16のリージョンがあり、ゲーム配信を世界中のリージョンから可能。コンテンツ配信ネットワーク(CloudFront)には60以上のエッジロケーションがある。実際の利用分だけのコスト。使った分だけなので需要に応じてサーバをスケール。過剰なキャパシティや無駄な投資が発生しない。キャパシティオーバーでゲーム需要に対応できずユーザーに不満が発生するような事態が起こらない。ゲームの成長に合わせてキャパシティーをコントロール可能。

開発/テスト

アジャイルに、いつでも必要なサービスやキャパシティを確保可能。イミュータブルなインフラストラクチャを構築できる。数分以内に必要なリソースを必要なだけ確保可能。デプロイ管理に関連するサービス。 AWS re:Invent 2016でClode Buildがリリースされた。 Code Commit、Code Build、Code Pipeleine、Code Deployによって開発をシームレスに行える。ディライトワークス株式会社の事例。 Fate/Grand Orderの事例。 Elastic Beanstalkでデプロイをオートメーション化。

ローンチ後の急速な成長期

オンラインゲームのフロー。ゲームAPIサーバにログイン。ゲームアセットをダウンロード。ゲームサーバのマッチメイクを実施。ゲームサーバへ接続し対戦。ゲームが終わったら結果の書き込み。ゲームAPIサーバ。一般的なゲームAPIのコンセプト。ゲームから見たAPI→HTTP+JSON、フレンドリスト、スコアボード、バイナリアセット配信。高可用性、拡張性が求められている。要求される構成。 Web+DBによるユーザーログイン、ロビー、スコアボード、プレゼントリストを実現。ゲームに応じて最適なリージョンの選択。日本なら東京。グローバルなら海外。 2つ以上のAZで、アプリ用のEC2を構築。ELB配下に配置。 RDS(Multi-AZ)で構成。静的コンテンツの配信。 S3+CloudFrontでの配信が一般的。 S3。高可用性のオブジェクトストレージ。オブジェクトをHTTP/HTTPSのエンドポイントで取得可能。 CloudFront。 CDNサービス。簡単にサイトの高速化とサーバ負荷軽減を実現。ユーザーに近いエッジロケーションからコンテンツを配信。サイバードの導入事例。 BFB 2016。ゲームのアセットファイルをS3+CloudFrontで配信。WAFも利用。スケール。フロントEC2をAutoScalingで。動的にキャパシティを変更。ユーザーの増加に合わせてキャパシティ増減。オートヒーリングも実現。 DEVSISTERSのクッキーランの事例。韓国の会社。 24時間の間にサービス変化に基づいて、夜中は2台、ピーク時は60台までオートスケール。 DBリードが増加した場合。 ElastiCacheによりDBサーバへのリードをキャッシュさせることでDB負荷を軽減。ガンホーのパズドラも同じような構成。ダウンロード数の推移、成長に伴って構成を変えないままサーバ数を増大。ゲームはDBライトヘビー。限界までキャッシング、キーバリュー型へ変更、バイナリストラクチャーの導入。最終的にDBがボトルネックになる。 Amazon Aurora。 Amazonがクラウド時代に合わせて作ったRDBMS。 MySQL互換、最大64TBまで自動でスケール。株式会社グラニの導入事例。ヴァルハラゲート。 Auroraがリリースされた直後からすぐに利用。 Auroraマイグレーション後、DB処理時間が15msから5.5msまで軽減。 RDS for MySQLからAuroraに変更することで年間2200万円のコスト削減。株式会社ガンホー・オンライン・エンターテイメントの事例。パズドラ。 Auroraを一晩で切り替え導入。 Amazon DynamoDB。 NoSQLデータベース。フルマネージドでスキーマレス。容量無制限。JSON型も対応。スキーマレスなのでゲームの長期運用に伴いユーザーやアイテムが増えても拡張を考えなくて良い。株式会社マイネットの導入事例。 DynamoDBで管理が難しいデータはRDB。 DynamoDBをメインのDBにすることで可用性やトラフィック増減をパラメータ変更だけで対応可能に。サーバーレスアーキテクチャ。仮想サーバであるEC2を使わずに、クラウドネイティブにアプリケーションやサービスを開発実行するためのアーキテクチャ。従来のゲームサーバ→API周りをELB+EC2で構築していた。クラウドネイティブなゲームアーキテクチャ。 API Gatewayを使うことでOSやインフラの管理不要、スロットリングやキャッシュ処理がフルマネージドで可能。 API Gatewayの裏にLambdaを配置。 2-Tierアーキテクチャ。 CognitoからTemporary Credentialsを取得、直接DynamoDBなどを叩かせる。解決される課題。インフラの構築や運用管理が不要、ビジネスの差別化に直接繋がらない機能のアプリ実装が簡単。面白いゲーム開発に集中できるようになる。各アーキテクチャのメリット/デメリット。従来のゲームサーバ。メリット→従来のノウハウが活かせる、実績が多く枯れた構成。カスタマイズ性が高い。デメリット→サーバのスペックや台数など、インフラを意識した設計が必要。サーバーレスアーキテクチャ。メリット→クライアント側の実装は従来とあまり変わらない。コスト効率が高い。デメリット→新規性が高くまだ枯れていない。 2-Tierアーキテクチャ。メリット→サーバーレスと一緒だがインフラの管理が不要、Web APIの設計が不要。最小限のリソースで構成できる。デメリット→新規性が高くまだ枯れていない。クライアントにSDKを入れる必要がある。三者択一でなく、メリット/デメリットで選択するのが良い。 AWS Lambdaを使ったゲームでの活用。 S3にゲームのキャプチャ画面がアップロードされるとサムネイル画像の作成やリサイズを実施。コピーライトの挿入も可能。ゲーム動画をElastic Transcoderでエンコードするような動作も可能。 DynamoDB StreamとLambdaを組み合わせて値チェックや別テーブルへのデータコピーなど。値に変更があったら非同期に値の確認を実施。ログインチェックにも使える。データチェックによってアイテム急増などのチート判定にも利用可能。従来のチェックではゲーム自体が重くなったが非同期なのでゲーム動作に影響がない。株式会社スクウェア・エニックスの事例。ドラゴンクエストXの思い出アルバム。ゲーム内の写真撮影をLambdaでサムネイル画像作成やcopyrightの追加を実施。処理時間が数時間から10数秒へ短縮。オンプレミスと比較して1/20まで削減。期間限定のグッズや装備が出ると記念写真撮影が起き負荷が急増するが対処できるようになった。ゲームサーバ。ゲームサーバのクラスタ。 AZ分散、フロントはEC2、ElastiCacheでセッションデータを保存。チャットなど保存すべきデータはRDSで。プッシュ通知はSNS。ゲームサーバの起動や登録の管理。管理サーバにてポーリング、ユーザー数などを確認してゲームサーバの自動起動やクラスタへの登録を実施。 Amazon GameLift。ゲームに関連する処理を全て置き換えてくれるサービス。ゲームのバイナリをアップロード、サーバ構成を作成、ゲームクライアントを設定して、ゲームを開始。セッションベースのマルチプレイヤーゲームのためのマネージドサービス。ユーザー数に応じてゲームサーバを増やす行為を自動でやってくれる。 Windows/LinuxのEC2サーバを立ち上げる。複数リージョン対応、世界中のユーザーに快適なゲーム体験を提供。ダウンタイム無しでバイナリのアップデートを実行可能。

ゲームの安定化

ビッグデータの活用。アナリティクスによって収益構造を改善。 Woogaの事例。バブルアイランド。開始直後にDAUが下がった。全てのレベルをクリアしたのか、レベルデザインが難しくて事例したのか、を分析。分析結果をゲームに反映させてDAUが向上。例。ゲームのレベルによる進行。ユーザー数の分析とハイレベルユーザーの滞留を分析することで、どのレベルがネックになるか分かる、など。ログの収集方法。最初はシンプルに、全てのログをS3に保存、出力結果をRedshiftに投入して分析。 Amazon Kinesis。ストリーミングデータを収集・処理するための古マネージドサービス。 Streams、Firehose、Analyticsの3種類。 Amazon Athena。 AWS re:Invent 2016で発表された新サービス。 S3に置いたデータに対して直接SQLクエリ可能。 Prestoベース。これまではS3上のデータから対象データを探すのにダウンロードする必要があったが不要になる。クラッシュオブクランの事例。日に4TBのデータをS3に配置。 HadoopクラスタをEC2で構築。 Kinesisを使ってデータをストリームで受信。 Woogaの事例。アイテムの価格変更をA/Bテストで実施。アイテム売り上げを24%増。まるまる同じサーバ環境を2つ作ってLBで振り分けすることでA/Bテスト環境を作成。 AWS Pinpoint。クライアントからエンゲージ情報を収集しセグメント化。セグメントを対象としてターゲットプッシュ通知を実施。

ユーザー数減少後

グローバル展開。ネットワークゲームの特徴。多数のユーザーが多地域からアクセス。通信速度の問題が発生する。複数のリージョンにゲームサーバを配置する場合。リージョン間のデータコピー。海を超えるとレイテンシが大きくなる。 100msを超えるレイテンシはリアルタイムゲームに影響を与える。多くのケースにおいて、同じタイムゾーン、同じ言語、同じくらいのレイテンシで遊ぶことをユーザーは望む。ロビーサーバとゲームサーバを分離。ロビーサーバだけ単一管理、ゲームサーバは複数地域に配置。中国の場合→ロビーサーバを中国にも配置、グローバルと分離。ランキングのようなものだけ、必要に応じて更に分離。疎結合に。 Playfabのアーキテクチャ。ゲームサーバを各地域に配置。ロビーサーバをメインリージョンに配置。